This section is intended to provide a background or context to the invention that is recited in the claims. The description herein may include concepts that could be pursued, but are not necessarily ones that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, what is described in this section is not prior art to the description and claims in this application and is not admitted to be prior art by inclusion in this section.
Various abbreviations that appear in the specification and/or in the drawing figures are defined as follows:
3GPPthird generation partnership projectCPcyclic prefixDLdownlinkeNBevolved Node B (LTE base station)E-UTRANevolved UTRANLTElong term evolution of UTRANMBMSmultimedia broadcast/multicast service(as defined in 3GPP)MBSFNmultimedia broadcast single frequency networkMCHmulticast channelMSAPMCH subframe allocation patternBCCHbroadcast control channelUMTSuniversal mobile terrestrial networkUTRANUMTS terrestrial radio access networkSFNsystem frame numberLTElong term evolutionNode Bbase stationeNBEUTRAN Node B (evolved Node B)UEuser equipmentULuplink (UE towards eNB)DLdownlink (eNB towards UE)EPCevolved packet coreMMEmobility management entityS-GWserving gatewayMMmobility managementHOhandoverPHYphysicalRLCradio link controlRRCradio resource controlRRMradio resource managementMACmedium access controlPDCPpacket data convergence protocolO&Moperations and maintenanceOFDMAorthogonal frequency division multiple accessSC-FDMAsingle carrier, frequency division multiple accessSIBsystem information blockFDDfrequency division duplexTDDtime division duplex
A communication system known as evolved UTRAN (EUTRAN, also referred to as UTRAN-LTE or as E-UTRA) has been under development within the 3GPP. The DL access technique is OFDMA, and the UL access technique is SC-FDMA.
One specification of interest is 3GPP TS 36.300, V8.5.0 (2008-05), 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Access Network (E-UTRAN); Overall description; Stage 2 (Release 8).
FIG. 1 reproduces FIG. 4 of 3GPP TS 36.300, and shows the overall architecture of the E-UTRAN system. The E-UTRAN system includes eNBs, providing the EUTRA user plane (PDCP/RLC/MAC/PHY) and control plane (RRC) protocol terminations towards the UE. The eNBs are interconnected with each other by means of an X2 interface. The eNBs are also connected by means of an 51 interface to an EPC, more specifically to a MME (Mobility Management Entity) by means of a S1MME interface and to a Serving Gateway (SGW) by means of a S1U interface. The S1 interface supports a many to many relationship between MMEs/Serving Gateways and eNBs.
The eNB hosts the following functions:
functions for Radio Resource Management: Radio Bearer Control, Radio Admission Control, Connection Mobility Control, Dynamic allocation of resources to UEs in both uplink and downlink (scheduling);
IP header compression and encryption of the user data stream;
selection of a MME at UE attachment;
routing of User Plane data towards Serving Gateway;
scheduling and transmission of paging messages (originated from the MME);
scheduling and transmission of broadcast information (originated from the MME or O&M); and
measurement and measurement reporting configuration for mobility and scheduling.
E-UTRAN is planned to support MBMS and, in particular, MBSFN operation in which macro diversity gain is accomplished by transmitting exactly the same signals from all base stations (eNBs) that are part of the MBSFN.
Reference with regard to MBMS can be made generally to 3GPP TS 36.331 V8.2.0 (2008-05), Technical Specification 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA) Radio Resource Control (RRC); Protocol specification (Release 8).
It should be noted that the above-referenced RRC specification is not an MBMS-specific reference in and of itself. It does, however, contain the discussed MBSFN subframe allocation signaling in the specified Release-8, so that Release-8 compatible terminals can properly treat possible MBSFN subframes in future networks. At present, the specification of MBMS itself has been postponed from Rel-8 to some later release.
MBMS can be provided either on a dedicated MBMS frequency layer or a mixed layer, where unicast transmission (including single-cell MBMS content) can be time multiplexed with MBSFN transmission on the same frequency layer. In the latter case, MBSFN transmission will occupy dedicated subframes (1-ms time intervals) whose structure differs from the normal unicast subframes in terms of, e.g., CP and reference signals.
It is noted that 3GPP TSG RAN WG2 has agreed to the following scheme for the allocation and signaling of radio frames that carry MBSFN subframes:
(1.) Radio frames containing MBSFN subframes appear when SFN mod N=Offset is true (SFN=System Frame Number is a running numbering of radio frames).
(2.) The parameters N and Offset are signaled on the BCCH.
(3.) Parameter N may take values 1, 2, 4, 8, 16, 32 (and is signaled with 3 bits).
(4.) Parameter Offset may take integer values between 0, . . . , 7 (and is signaled with 3 bits).
The value range of N corresponds to having in every period of 32 radio frames, respectively, 32, 16, 8, 4, 2, or 1 frame containing MBSFN subframes. More than one such allocation can be concurrently used, with the cost of each such allocation requiring altogether 9 signaling bits on the BCCH, i.e. the parameters N, Offset, and Subframeallocation (not mentioned above).
At least one problem with this proposal is the limited set of possible reservations of MBSFN subframes per time period (or rates of MBSFN subframes) per allocation: given that in any one allocation each frame containing MBSFN subframes is signaled to contain anywhere between 1 and 7 MBSFN subframes, the reservations of MBSFN subframes every 32 frames (i.e. 320 subframes or 320 ms) are limited to all the pairwise products from the sets {1, 2, 3, . . . , 7} and {32, 16, 8, 4, 2, 1}. For example, if the network operator wishes to start an MBMS service whose data rate is estimated to require 129 MBSFN subframes per 320 ms, the operator must in fact reserve 160 MBSFN subframes (or use more than one allocation and correspondingly at least double the number of signaling bits). This inefficient form of scheduling, in this example, means that 31 MBSFN subframes (and 6 entire radio frames) per 320 ms are reserved for no purpose, thereby wasting valuable bandwidth.